Systems and methods for dynamic bridge linking

ABSTRACT

Embodiments of the present invention generally relate to systems and methods for implementing telecommunications. More specifically, various embodiments of the present invention provide methods for interconnecting real-time communication links. Such methods include receiving the status of at least two communication links. The communication links may be established between endpoints and bridges in a network. One of the bridges associated with one of the communication links is selected to operate as a host bridge based at least in part on the status of the communication links. Then, after receiving the status from at least two of the communication links, the selected host bridge is automatically caused to initiate another communication link with at least another bridge associated with one of the aforementioned communication links.

The present application is a continuation in part of U.S. patentapplication Ser. No. 10/423,693, entitled “System and Method forEstablishing and Controlling an On-Demand Teleconference by a RemoteComputer”, and filed Apr. 25, 2003, by Huber et. al. which claims thebenefit of U.S. Provisional Patent Application No. 60/375,869 filed Apr.26, 2002 and is a continuation in part of U.S. patent application Ser.No. 10/121,409, entitled “System and Method for Establishing andControlling an On-Demand Teleconference by a Remote Computer”, and filedby Huber which claims the benefit of U.S. Provisional Patent ApplicationNo. 60/283,870 filed Apr. 13, 2001. Each of the aforementioned patentapplications is incorporated herein by reference in its entirety.

BACKGROUND

Embodiments of the present invention generally relate to systems andmethods for implementing telecommunications. More specifically,embodiments of the present invention relate to systems and methods fordynamically linking telecommunication bridges.

Existing teleconferencing systems are capable of establishing atelephone conference call or teleconference between multipleindividuals. One of the most common methods for establishing ateleconference involves a teleconference host or sponsor (i.e., theindividual who desires to have a teleconference), to schedule theteleconference with a human teleconference operator in advance of theteleconference. The operator typically initiates a software applicationsuch as, Windows™ Operating Console that provides control of all callsoccurring on a particular bridge. Using the software, the operator opensa pre-loaded instance of the call, and the necessary link line(s) forthe proposed conference call are preconfigured in a table detailing theproposed call. At a pre-determined point in time, the operator dials toa second bridge, waits for the system or another operator to answer thecall, and then manually links the calls by clicking an input on theoperator's user screen. As will be appreciated, the aforementionedapproach may be labor intensive, may not provide an ability to linkcalls on demand, and may involve various charges incurred while a callis pre-setup but not currently being utilized by callers.

Thus, for at least one or more of the aforementioned reasons, a needexists for advanced systems and methods for implementingtelecommunication connections.

SUMMARY OF THE INVENTION

Embodiments of the present invention generally relate to systems andmethods for implementing telecommunications. More specifically,embodiments of the present invention relate to system and methods fordynamically linking telecommunication bridges.

Various embodiments of the present invention provide methods forinterconnecting real-time communication links. Such methods includereceiving the status of at least two communication links. Thecommunication links may be established between endpoints and bridges ina network. One of the bridges associated with one of the communicationlinks is selected to operate as a host bridge based at least in part onthe status of the communication links. Then, after receiving the statusfrom at least two of the communication links, the selected host bridgeis automatically caused to initiate another communication link with atleast another bridge associated with one of the aforementionedcommunication links. In some cases, selecting the host bridge includesconsideration of whether the first status indicates a host status,and/or whether the second status indicates the host status. In othercases, selecting the host bridge includes consideration of whether oneor more of the bridges associated with the various communication linkshas sufficient available capacity. In yet other cases, selecting thehost bridge is based at least in part on the determination of whetherone or more of the bridges associated with the communication links isleast cost mutable.

In various instances of the aforementioned embodiments, the methodsfurther include recording respective entries in a database table thatincludes one or more call parameters related to a particular one of thecommunication links. In some cases, the call parameters include one ormore of the following: a bridge identifier, a call status, a portnumber, a conference passcode, and a bridge status. Further, in somecases, the status associated with the communication links is obtained bypolling the database table. In some instances of the aforementionedembodiments, automatically causing the selected bridge to initiate acommunication link to another bridge includes monitoring a databasepopulated with a plurality of communication link status information toidentify when the first communication link and the second communicationlink have been established. In some cases, initiating the communicationlink between the host bridge and another bridge includes: determining anaccess property of the non-host bridge; communicating with the non-hostbridge using the access property; and transmitting a validation codefrom the non-host bridge to the host bridge. In one or more cases, thevalidation code is a guest passcode.

Other embodiments of the present invention provide a computer-readablestorage medium containing a set of instructions capable of causing oneor more processors to: receive a first status associated with a firstcommunication link that is established between a first endpoint and afirst bridge in a network; receive a second status associated with asecond communication link, that is established between a second endpointand a second bridge in the network; select one of the first bridge andthe second bridge to operate as a host bridge; and cause the selectedbridge to initiate a third communication link with the non-selected oneof the first bridge and the second bridge after receiving both the firststatus and the second status. Selection of one of the first bridge andthe second bridge to operate as a host bridge is based at least in parton the first status and the second status.

Yet other embodiments of the present invention provide methods forinterconnecting real-time communication links. Such methods includereceiving a first status associated with a first communication link anda second status associated with a second communication link. The firstcommunication link is established between a first endpoint and a firstbridge in a network and the first status includes information related tothe first communication link. Similarly, the second communication linkmay be established between a second endpoint and a second bridge in thenetwork. The methods further include determining if the first bridge isa host bridge based at least in part on the first status. In addition,the first bridge is dynamically linked to the second bridge based atleast in part on the first status and the second status. In thisconfiguration, the first bridge acts as a host bridge for a multi-partycommunication ongoing between at least the first endpoint and the secondendpoint.

In some cases, the aforementioned method further includes determiningthat the second bridge is the host bridge based at least in part on thesecond status; receiving a third status associated with a thirdcommunication link that is established between a third endpoint and athird bridge in the network; and dynamically linking the thirdcommunication link to the first communication link and the secondcommunication link by creating a fourth communication link between thehost bridge and the third bridge. In some cases, determining the hostbridge based at least in part on the first status includes determiningif a call passcode associated with the first communication link is ahost passcode or a guest passcode.

This summary provides only a general outline of some embodiments of thepresent invention. Many other objects, features, advantages and otherembodiments of the present invention will become more fully apparentfrom the following detailed description, the appended claims and theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

In the Figures, similar components and/or features may have the samereference label. Further, various components of the same type may bedistinguished by following the reference label with a second label thatdistinguishes among the similar components. If only the first referencelabel is used in the specification, the description is applicable to anyone of the similar components having the same first reference labelirrespective of the second reference label.

FIG. 1 is a block diagram of one embodiment of the present invention;

FIG. 2 depicts the format of a transaction record used by the presentinvention;

FIG. 3 depicts the process used to connect a caller to a conferencecall;

FIG. 4 depicts the process used to control a teleconferencing system viaa remote computer;

FIG. 5 depicts a conference list web page constructed in accordance withthe present invention;

FIG. 6 depicts the bridge status web page constructed in accordance withthe present invention;

FIG. 7 depicts the customer viewing web page constructed in accordancewith the present invention;

FIG. 8 depicts the user web page constructed in accordance with thepresent invention;

FIG. 9 depicts the customization web page constructed in accordance withthe present invention;

FIG. 10 depicts the new customer web page constructed in accordance withthe present invention;

FIG. 11 depicts the new department web page constructed in accordancewith the present invention;

FIG. 12 depicts the new subscriber web page constructed in accordancewith the present invention;

FIG. 13 depicts the bulk subscriber web page constructed in accordancewith the present invention;

FIG. 14 depicts the passcode troubleshooting web page constructed inaccordance with the present invention;

FIG. 15 depicts the subscriber status web page used in accordance withthe present invention;

FIG. 16 depicts a conference detail web page constructed in accordancewith the present invention;

FIG. 17 depicts the traffic feed web page constructed in accordance withthe present invention;

FIG. 18 depicts the pricing model display web page constructed inaccordance with the present invention;

FIG. 19 depicts the pricing model entry web page constructed inaccordance with the present invention;

FIG. 20 depicts the invoice list web page constructed in accordance withthe present invention;

FIG. 21 depicts the totals mode invoice display web page constructed inaccordance with the present invention;

FIG. 22 depicts the printable invoice display web page constructed inaccordance with the present invention;

FIG. 23 depicts an alternate embodiment of the present invention;

FIG. 24 depicts an alternate method and embodiment of the presentinvention;

FIG. 25 depicts one process in accordance with some embodiments of thepresent invention for controlling a system in accordance with one ormore embodiments of the present invention;

FIG. 26 illustrates an exemplary dynamically linked bridge formed usinga bridge coordinator in accordance with one or more embodiments of thepresent invention;

FIG. 27 illustrates a flow diagram of call routing in accordance withsome embodiments of the present invention;

FIG. 28 illustrates a flow diagram of another call routing method inaccordance with other embodiments of the present invention;

FIG. 29 illustrates another exemplary dynamically linked bridge formedusing a bridge coordinator in accordance with various embodiments of thepresent invention;

FIG. 30 provides a more particular example of dynamically linked bridgesillustrating particular geographies and endpoints that may be servicedusing systems and methods in accordance with one or more embodiments ofthe present invention;

FIG. 31 illustrates an exemplary table which may be used in accordancewith some embodiments of the present invention;

FIG. 32 illustrates an exemplary table containing PSTN dial-out numberswhich may be used in accordance with various embodiments of the presentinvention;

FIG. 33 illustrates an exemplary table containing IP dial-string whichmay be used in accordance with one or more embodiments of the presentinvention; and

FIG. 34 is an example of a computer system that may be utilized inrelation to one or more embodiments of the present invention.

DETAILED DESCRIPTION

Embodiments of the present invention generally relate to systems andmethods for implementing telecommunications. More specifically,embodiments of the present invention relate to system and methods fordynamically linking telecommunication bridges.

In accordance with various embodiments of the present invention, systemsand methods for performing Dynamic Bridge Linking (DBL) are described.For example, a method for DBL is described for automatically linkingbridges without the use of manual operator intervention. According toone embodiment, a bridge coordinator monitors the bridges in ateleconferencing system. The bridge coordinator may be a separate systemwhich is configured to recognize when multiple bridges should be linkedto effectuate a desired telecommunication. According to one embodimentof the present invention, when the bridge coordinator determines thatmultiple bridges need to be linked, the bridge coordinator automaticallylaunches a dial-out process. Further, in some embodiments of the presentinvention, the bridge coordinator is capable of determining the leastexpensive dialing option, such as PSTN, VOIP, and/or the like.

As an operational example, caller A may dial into one bridge while latercaller B may dial into a second bridge each intending to be connected tothe same teleconference. Since each bridge may operate independent ofthe other, it may be that neither bridge recognizes that the conferenceis already in progress. In some embodiments, the bridge coordinator maybe or may include a software program that monitors the activity of anumber of bridges within a network. When the bridge coordinatorrecognizes that caller A and caller B should be on the same conferencecall, the bridge coordinator can designate one of the bridges (oranother bridge altogether) to operate as a host bridge. The host bridgemay initiate a dial out to other bridges servicing communication linksthat are to be included on the same conference call including thecommunication link servicing caller B. The process may be repeated untilall callers are properly connected.

One or more benefits may be provided as a result of various embodimentsof the present invention. For example, various embodiments of thepresent invention may reduce interaction with a live operator, and/ormay reduce time spent idling as communication links are dynamicallyformed rather than statically formed. As used herein, the term“dynamically” is used in its broadest sense to mean the formation of alink at a point in time when the link comes into active use by two ormore participants in a communication session. In contrast, a“statically” formed link is generally set-up in anticipation of aparticular communication session, and typically before more than oneparticipant has joined the communication session. In contrast todynamically linking bridges, the traditional, operator-assisted methodinvolves establishing links in anticipation of a communication session.This may incur long-distance charges even before the advent of thecommunication session. Using one or more embodiments of the DBL methodcan provide the establishment of communication links as they are needed,thus minimizing the costs of any toll services. In addition, in theembodiments of the present invention that provide for automatic set-upand linking, there is a reduced need to employ operators. As yet anotheradvantage found in some embodiments of the present invention, users maybe able to dynamically link to a communication session by dialing in tobridges local to the particular users, rather than being required todial in to a predetermined bridge that may not be local to one or moreof the users.

Yet another benefit found in one or more embodiments of the presentinvention is that of bridge scalability. For example, if a call exceedsthe capacity of a bridge, additional bridges may be employed on anas-needed basis. The bridges will recognize when a link needs to beestablished and establish the link automatically. Based on thedisclosure provided herein, one of ordinary skill in the art willrecognize that one or more of the aforementioned advantages, and/or someother advantages are found in the various embodiments of the presentinvention described herein.

Embodiments of the present invention may be provided as a computerprogram product which may include a computer readable medium havingstored thereon instructions which may be executed by a computer (orother electronic devices) to perform a process. Based on the disclosureprovided herein, one of ordinary skill in the art will recognize avariety of computer readable media that may be used in relation tovarious embodiments of the present invention. As just some examples, thecomputer readable medium may include, but is not limited to, floppydiskettes, optical disks, compact disc read-only memories (CD-ROMs), andmagneto-optical disks. ROMs, random access memories (RAMs), erasableprogrammable read-only memories (EPROMs), electrically erasableprogrammable read-only memories (EEPROMs), magnetic or optical cards,flash memory, and/or combinations thereof. Moreover, embodiments of thepresent invention may also be dpwnloaded as a computer program product,wherein the program may be transferred from a remote computer to arequesting computer by way of data signals embodied in a carrier wave orother propagation medium via a communication link (e.g., a modem ornetwork connection).

For the sake of illustration, various embodiments of the presentinvention have herein been described in the context of computerprograms, physical components, and logical interactions within moderncommunication networks. Importantly, while these embodiments describevarious aspects of the invention in relation to modern communicationnetworks and computer programs, the method and apparatus describedherein are equally applicable to other systems, devices, and networks asone skilled in the art will appreciate. As such, the illustratedapplications of the embodiments of the present invention are not meantto be limiting, but instead exemplary. Other systems, devices, andnetworks to which embodiments of the present invention are applicableinclude, but are not limited to, other types of communication andcomputer devices and systems. More specifically, embodiments areapplicable to communication systems, services, and devices such as cellphone networks, PSTN networks, VOW networks, IP networks, videoconferencing, and the like. In addition, embodiments are applicable toall levels of communications from the local community communications toworld wide communication systems.

The terms “connected” or “coupled” and related terms are used in anoperational sense and are not necessarily limited to a direct physicalconnection or coupling. Thus, for example, two devices may be coupledirectly, or via one or more intermediary media or devices. As anotherexample, devices may be coupled in such a way that information can bepassed therebetween, while not sharing any physical connection on withanother. Based on the disclosure provided herein, one of ordinary skillin the art will appreciate a variety of ways in which connection orcoupling exists in accordance with the aforementioned definition.

The phrases “in one embodiment,” “according to one embodiment,” and thelike generally mean the particular feature, structure, or characteristicfollowing the phrase is included in at least one embodiment of thepresent invention, and may be included in more than one embodiment ofthe present invention. Importantly, such phases do not necessarily referto the same embodiment.

If the specification states a component or feature “may”, “can”,“could”, or “might” be included or have a characteristic, thatparticular component or feature is not required to be included or havethe characteristic.

FIG. 1 shows a block diagram of a system 10 for establishing andcontrolling an on-demand teleconference on a bridge 102 by one or moreremote computers 140. Teleconference bridge 102 is connected viaconnection 103 to a maintenance and administrative terminal (“MAT”) 104and via a plurality of ports 150 on bridge 102 to telephones 108 via theconventional Public Switched Telephone Network (“PSTN”) 106. Optionally,bridge 102 may be connected via a plurality of ports 150 on bridge 102to telephones 108 via an IP connection 110.

In the preferred embodiment, a high speed serial connection is used forconnection 103. Those skilled in the art will recognize, however, thatan Ethernet, parallel or other connection could be used for connection103.

Bridge 102 is preferably a CONTEX 240 teleconferencing bridgemanufactured by Compunetix, Inc. of Monroeville, Pa. having 240 or moreports. Bridge 102 provides various digital signal processing,conferencing, call flow, and other conference-related functionality thatallows several individuals to participate in a telephone conference calland allows several conference calls to be in progress at any given time.Those skilled in the art will recognize that other teleconferencingbridges providing similar functionality may also be used, with departingfrom the spirit and scope of the present invention.

Bridge 102 is managed and controlled by MAT 104, which is implemented assoftware residing on a workstation or other processing platform. MAT 104is connected to a small database 107 and executes a real-time billinginterface 105, which is an application programming interface (API). Asdiscussed in greater detail below, billing interface 105 allowsinformation to be sent and received by MAT 104.

In the preferred embodiment, MAT 104 and billing interface 105 are aworkstation or other processing platform that executes version 1.0 orhigher of the Real-Time Bridge Interface which is also sold byCompunetix.

Referring to FIG. 1 and FIG. 2, those skilled in the art will recognizethat the billing interface 105 of MAT 104 creates a transaction record200 whenever certain activities occur on bridge 102. Each transactionrecord 200 is temporarily stored in database 107.

FIG. 2 shows the general format of a transaction record 200.Specifically, transaction record 200 comprises header information 201and one or more parameters 202.

Header 201 contains information for generally categorizing transactionrecord 200. For example, header information 201 may indicated thattransaction record 200: (1) is an inquiry as to the validity of acertain host or guest passcode, (2) is a response to a validity requestindicating whether a host or guest passcode is valid or invalid, (3)contains information concerning the attributes associated with aparticular passcode, (4) indicates a change to the status of a port 150located on bridge 102, (5) is an inquiry concerning the number of storedtransaction records 200 in a particular device, (6) an inquiryconcerning a specific transaction record 200, (7) is intended toindicate the start time or end time of a particular conference, or (8)is intended to change user data.

One or more parameters 202 may be used within transaction record 200.Parameters 202 are the elements that actually transmits the data withina transaction record 200. Representative parameters 202 are shown inTable 1.

TABLE 1 Parameter Description Port Port 150 of bridge 102 from which thepasscode was entered Host Passcode Passcode associated with host. GuestPasscode Passcode associated with guest. Scheduled Date Date for whichthe conference is scheduled Scheduled Time Time for which the conferenceis scheduled Scheduled Duration Scheduled duration of the conferenceConference Type The type of conference call Conference Name Nameassociated with conference. Conference Code Billing code associated withthe conference. Scheduled Number Scheduled number of parties for a OfParties particular conference. Connect Time Limit Total prepaid connecttime left for this code set.

For a given conference call there might be 20 or more transactionrecords 200 produced by billing interface 105, for actions such as:connecting to the bridge, requesting a passcode be validated, enteringthe conference, hanging up, and the act of the conference beingterminated, or torn down. For example, if a teleconference attendeehangs up a phone 108 connected to bridge 102, billing interface 105 willgenerate a transaction record 200 in which header 201 will containinformation identifying that the transaction is intended to convey achange in the status of one of the ports 150 of bridge 102. Parameters202 will contain information concerning the actual action that hasoccurred (i.e., a disconnect), the specific port 150 experiencing thestatus change, and the time the status changed occurred.

Referring again to FIG. 1, billing interface 105 sends a copy of any newtransaction records 200 generated by bridge 102, via a connection 112,to a listener 114. In the preferred embodiment connection 112 is an IPconnection connected to a TCP port (not shown) on Listener 114.

Listener 114 collects each transaction record 200, checks each forinternal data errors, and places the transaction record 200 in adatabase 116. In the preferred embodiment, Listener 114, is implementedas software residing on a workstation or other processing platform andcontinuously screens a pre-specified port on the MAT 104 (by defaultTCP/IP Port 7300) for any new incoming data. Those skilled in the artwill recognize that for particular applications, Listener 114 can beprogrammed to convert transaction record 200 to a more efficientstructure or discard unneeded data in transaction record 200, therebyallowing more information to be stored.

When system 10 is initially started, billing interface 105 on MAT 104and Listener 114 exchange ‘handshaking’ information (such astransmission speeds) with each other, ensuring that both systems areoperating properly and recognize each other. MAT 104 and Listener 114begin to exchange data, once the devices have established acommunication session.

MAT 104 and Listener 114 continue to communicate to ensure that all thetransaction records generated by bridge 102 are actually received andstored by Listener 114 in database 116. In the preferred embodiment, MAT104 and Listener 114 will, every 10 minutes, attempt to verify thecontents of databases 107 and 116 by comparing the number of transactionrecords 200 stored in the databases 107 and 116. If the number oftransaction records 200 stored in the database 107 and 116 does notmatch, a resynchronization operation will begin.

During a resynchronization operation, Listener 114 will request MAT 104to re-send all the transaction records 200 stored in database 107 andcompare the newly received transaction records 200 to those stored inthe database 116 of Listener 114. If Listener 114 identifies any newtransaction records 200 that have not been previously stored in database116, it will place the new transaction records 200 in database 116.Checksums are used to ensure that data is not corrupted.

After the resynchronization operation has occurred, MAT 104 and Listener114 will attempt to re-verify the contents of databases 107 and 116 bycomparing the number of transaction records 200 stored in the databases107 and 116.

Because Listener 114 only receives and process transaction records 200it doesn't know how a participant is connected to bridge 102 (e.g., viaPSTN 106 or IP connection 110). Therefore, Listener 114 operatesregardless of how an attendee is connected to Bridge 102. If differentbilling types are required for connections via PSTN 106 or IP 110, DNISinformation can be used and analyzed as part of the billing process.

The transaction records stored in database 116 of Listener 114 are alsoreplicated and sent to a database 122 connected to a billing server 120via connection 118. In the preferred embodiment, billing server 120 isimplemented as software residing on a workstation or other processingplatform. As will be discussed in greater detail below, billing server120 processes transaction records 200 by applying various billing rulesestablished by users. Once the transaction records 200 are processed bybilling server 120, the information can be passed to web server 130through standard SQL ADO (ActiveX Data Object) drivers. As will bediscussed in greater detail below, this enables a user to directly viewthe call transaction records, or summaries thereof.

A web server 130 is also connected to billing server 120 via connection125. In the preferred embodiment, web server 130 is implemented assoftware residing on a workstation or other processing platform andexecutes a web interface 133. Web server 130 is connected via webinterface 133 to the internet 135 and ultimately to remote computers140.

A user ID and password are issued to each individual authorized toaccess web interface 133. The user ID and password used to access webinterface 133 are separate and distinct from the host and guestpasscodes used to access bridge 102. By accessing web interface 133,teleconference hosts can establish teleconferences without the need of ahuman operator and perform a variety of administrative functions.

When a user activates, or deactivates, a host or guest passcode usingweb interface 133, the information is sent to billing server 120 whichtransmits (replicates) the data to databases 107, 116 and 122. When ahost or guest passcode is presented to bridge 102 via a telephone 108,bridge 102 can determine if the host or guest passcode is valid byhaving MAT 104 compare the received passcode to the valid passcodesstored in database 107. If the passcode is valid. MAT 104 instructsbridge 102 to place that call into conference.

FIG. 3 describes in greater detail the process used by a teleconferenceattendee to be placed into a conference call. As shown in step 302, theattendee using a telephone 108 connects to bridge 102 via PSTN 106 or IPconnection 110. As shown in step 304, upon connecting, bridge 102prompts the attendee to enter a guest or host passcode. At step 306,bridge 102 has MAT 104 search database 107 to determine whether thepasscode entered by the attendee matches the passcode to a conferencecall currently in progress on bridge 102. If the entered passcodematches the passcode of a conference already in progress, the attendeeis placed into that conference at step 308. If the passcode does notmatch the passcode associated with a conference currently in progress,referring to step 310, bridge 102 has MAT 104 search database 107 todetermine whether the passcode entered by the attendee matches thepasscode associated with a conference that is scheduled to start aroundthe time of the attendee's call. If the entered passcode matches thepasscode of a conference that is scheduled to start around the time ofthe attendee's call, the attendee is placed into that conference at step308. If the entered passcode does not match the passcode of a conferencethat is scheduled to start around the time of the attendee's call,referring to step 312, bridge 102 issues a query to database 116attached to listener 114 to determine whether the entered passcode is avalid passcode. If the entered passcode is a valid passcode, bridge 102creates a conference and the attendee is placed into that conference atstep 308. If the entered passcode is not a valid passcode the call isterminated at step 314.

In the preferred embodiment, each user who is authorized to useinterface 133 is given a login security level appropriate to theirposition in the system hierarchy. Those skilled in the art willrecognize that different security level classifications or a differentnumber of security levels can be used in a manner consistent with theteachings of the present invention. This information is stored indatabase 122. The security levels for various types of users are shownin Table 2.

TABLE 2 Security Level Type of User Level 7 System Administrator Level 6Customer Service Manager Level 5 Customer Service Representative Level 4Provider Level 3 Customer Level 2 Customer Level 1 Individual User

The preferred embodiment of the present invention utilizes ahierarchical design for establishing security levels and relatedaccounts. The top 3 security levels are intended to be used by employeesof the entity controlling the present invention, while the bottom 4levels are intended to be used by the customers of the entitycontrolling the present invention.

Users assigned to the highest 3 security levels are able to view varioustransaction records 200 stored in database 122 (or any other relatedinformation stored in database 122) that is associated with any systemuser having a lower security level. It is possible to place variousrestrictions on the particular type of information or transaction record200 a user having a particular security level may view.

With respect to the lowest 4 security levels, a user at a given securitylevel is permitted to access the information associated with a user at alower security level, provided that the user at the lower security levelis within the hierarchy associated with the user at the higher securitylevel. A security level 4 or lower user is not permitted to viewinformation associated with a user in a different hierarchy.

In the preferred embodiment, a security level 4 setting allows thegreatest access to information stored in database 122 by an individualnot employed by the entity controlling the present invention.

FIG. 4 describes in greater detail the process used by a user to accessweb interface 133 by a remote computer 140. Referring to step 402, theuser opens their web browser (not shown) on remote computer 140 andenters a URL for the web interface 133 into the address line of the webbrowser. At step 404, interface 133 prompts the user to enter a user IDand password and click on the login button at the bottom of the dialogbox. At step 406, the web interface 133 compares the entered informationwith the information stored in billing database 122. If the informationdoes not match, the user is denied access at step 408. If the userentered a valid user ID and password, the user will be allowed access toweb interface 133 and an initial menu (not shown) having one or more ofthe menu categories and menu items identified in Table 3, will bedisplayed based on the user's security level.

TABLE 3 Menu Category Menu Items Conferences Conference List - Displaysthe current list of conferences for the month or year based on theselected filter Bridge Status - A snapshot of the activity on a givenbridge automatically refreshed every 20 seconds Usage Summary - Abreakdown of the number of ports 150 per day that were used, either byprovider or a total number System Customers - Displays a list ofindividual customers Departments - Displays a list of individualdepartments Subscribers - Displays a list of individual subscribersProviders Information - Displays a list of individual providersContacts - Information about an individual contact within a providerthat is not a customer Traffic Feed - Displays data based on providertraffic Invoices - A default setting that lists all open invoices for aprovider Maintenance My Web settings - Allows a user to set theirindividual settings DNIS Rates - Allows ACT to set surcharges based onDNIS Termination Providers - Displays a list of individuals who provideaccess into the IP system Dialout Rates - Allows ACT to specifytransport rates Logout Logout - terminate access to web interface 133

FIG. 5 depicts the conference list web page 501 that is displayed whenthe user selects the Conference List menu item. Conference list web page501 displays, in real time, a list of conferences conducted at the userssecurity level and below. Web page 501 defaults to the current month andyear, and displays all conferences. The user can review historicalconference lists and details by simply selecting the appropriate monthand year in the drop-down boxes 502. The user is also given the optionto switch between pages. The system can sort the view by simply clickingon the appropriate customer drop-down box 503, department drop-down box504 and subscriber drop-down box 505. For users having a security levelgreater than level 4, the user can also filter teleconferences byprovider, by selecting a provider from provider drop-down box 506. Inthe preferred embodiment, the conferences, displayed on web page 501,contain the fields identified in Table 4.

TABLE 4 Field Description Conference a unique number identifying theconference call ID Conference a value that is generated by combining theConference ID Name and the name of the bridge 102 the conference wasconducted on. Date the date the conference call was conducted Start timethe conference start-time in GMT End time the conference end-time in GMTSubscriber the name of the user who hosted the conference Callers numberof attendees on conference call Duration duration of conference callfrom the time first person joined to the time the last persondisconnected Connected sum of the connection time of all participants tobridge 102 Billable sum of the billable connection time for allparticipants

Referring to FIG. 5 and FIG. 16, a user can cause web interface 133 todisplay a conference detail web page 1601 by simply clicking on theconference name for the particular conference of interest. Web interface133 will then display a summary of the specific conference informationfrom the previous web page 501 plus specific details for each conferenceconnection as set forth in Table 5.

TABLE 5 Field Description Host shows the host connection with an X Dialindicates the conference participant was dialed from the system Out Portindicates exactly what port 150 on the bridge the conference participantwas on Phone shows the telephone number dialed or the DNIS number of theaccess gateway Name indicates the conference participant's statushost/guest/dial-out Blank this field can be used to enter informationsalient to the Billing subscriber about the conference call e.g. (costcenter code, Field matter number, charge back code, etc). The user canthen click on the edit key and click on the billing reference field;type the appropriate information and click save.

FIG. 6 depicts the bridge status web page 601 that is displayed when theuser selects the Bridge Status menu item from the initial menu. Bridgestatus web page 601 displays a real-time view of the status of all theports 150 being used on bridge 102. Web page 601 provides the ability toverify port 150 availability prior to creating a conference requiring alarge number of ports 150 and the ability to monitor the usage load onbridge 102.

The initial view of the bridge status web page 601 is a high-level view.The status indicator label for each port 150 of bridge 601 indicates thepurpose each port 150 is being used for. Additional details can bedisplayed by clicking on the details button 602 at the top of the page.The detailed view displays the designation (or name) of the particularport 150, conference ID, the subscriber name, the time port 150 wasfirst used and the total amount of time port 150 was in use.

A specific customer's usage of bridge 102 can be displayed by simplyclicking on the customer drop-down box 603 and selecting a specificcustomer. Performing this action will display the following informationfor a particular customer: available ports 150; type of call(dial-in/dial-out); passcode used (with a link to the subscriber'sinformation); time connected and duration connected.

Only users with a higher security level are allowed to see details abouta user having a lower security level. For example, referring to the webpage 701 depicted in FIG. 7, the customer viewing web page 701, isunable to view any details concerning port 70 and port 71 as indicatedby the symbol “X.X”.

FIG. 8 depicts a user web page 801 that is displayed when the userselects the menu item from the initial menu. Web page 801 is used fordisplaying: usage graphs; the number of passcodes issued; the totalconferencing minutes month-to-date and annually; total conferencingrevenue month-to-date and annually; percent of bridge port utilization.

The system menu has at least 3 drop down menus: providers 805, customer806 and Department 807. By clicking on any one of menus, the user cansee a summary of each level in the hierarchy. The provider drop-downmenu 805 displays a summary of all customers, departments and userswithin the selected provider's hierarchy. In the preferred embodiment,this menu is accessible only to administrative staff with an accesslevel of 5 or higher and provides a summary of all providers in thesystem. The provider ID, name, billing address information, assignedbridge and system status will also be displayed.

The customer drop-down menu 806 displays a summary of all customerswithin a selected hierarchy. The customers are listed alphabeticallywith all departments listed for each customer.

The department drop-down menu 807 displays a summary of all departmentsestablished within a selected customer. This information may be listedalphabetically by department name with the provider name and customername as headers.

FIG. 9 depicts the customization web page 961 that is displayed when theuser accessing web interface 133 selects the my web settings menu itemfrom the initial menu. Web page 901 displays the available customizationfeatures. For example, a security level 4 user can change the customer,department and subscriber labels of the top level menus to reflect theappropriate nomenclature for each business using the present invention.Once changed, every user within that hierarchy who logs on to the systemwill see the new label names.

Each user can also change their password, greeting name and e-mailaddress. They can also change the page layout of their account (e.g.,number of records displayed per page, how the subscribers are listed andif they would like the providers name listed). Any changes submitted onweb page 901 will be saved in database 122 and will be effective thenext time the user logs into web interface 133.

FIG. 10 depicts the new customer web page 1001 that is used to add a newcustomer, such as a business, to database 122. The appropriate billingand contact information is submitted to web page 1001, via interface133. The maximum number of subscribers a customer is permitted to haveat any time can also be limited by placing an appropriate value in field1005. Once all information has been completed the person submitting theinformation to interface 133 clicks the save button and the informationis stored in database 122.

Web page 1001 also displays relevant information for each customer suchas the customer name, contact name, type of contact e.g. (technical,billing, sales, etc.), their phone number, fax number, city, state andcountry.

FIG. 11, depicts a new department web page 1101 that is used to addinformation for a new department to database 122. Once the customerinformation has been stored in database 122, one or more new departmentsmay be added to database 122 by submitting a completed new departmentweb page 1101 to interface 133.

FIG. 12 depicts a new subscriber web page 1201 that is used to add a newsubscriber to database 122. One or more new subscribers can be added todatabase 122 by submitting a new subscriber web page 1201 to database122, via web interface 133.

FIG. 13 depicts a create bulk subscriber web page 1301 that is used toquickly add information concerning a number of subscribers to database122. Web page 1301 is used to support a reservation-less unattendedconferencing platform.

Passcodes are typically generated in pairs, host and guest. By enteringa host passcode into bridge 102 from telephone 108, a conference can beinitiated, administrative functions can be performed and billing for theconference commences.

in addition, a user can access the detail call records for any customer,department, or subscriber below them in the hierarchy. The user can alsoactivate, deactivate any level within the hierarchy thereby activating,deactivating all host/guest passcodes issued at and below that level.

Web page 1301 can be used to: create individual and hulk subscriberaccounts; activate and deactivate passcodes; restrict the usage topredetermined, limits; enable special conference feature by passcode;and set expiration dates of the passcodes. Generating passcodes is apowerful feature of the system. In the preferred embodiment only usershaving a security level 3 or greater authorization are permitted tocreate passcodes. In creating a host/guest passcode pair, the featuresidentified in Table 6 can be assigned to any given user and stored indatabase 122.

TABLE 6 Category Features Host Information Passcode (this can berandomly selected or specifically requested, if available) Subscribername Account expiration date Telephone number FAX number Email addressCompany name Account number Passcode Features Talk/listen mode Entrancetones Exit tones Record participant names Play custom greeting messageAccount limits Maximum participants per conference Maximum minutes perconference Total number of conferences allowed Total conference timelimit

There are three ways passcode numbers can be assigned to each user usingweb page 1301. First, a random passcode can be designated for each user.Second, each passcode can by selected sequentially within a givenstarting and ending range, depending on availability. Finally the hostand guest passcodes can be selected randomly.

Once bulk passcodes are created, a customer level user might wish toassign and activate hulk passcodes by using spreadsheet software oranother third-party application. This is facilitated by downloading thepasscodes to remote computer 140, from database 122, via web server 130and interface 133. Passcodes can be downloaded in comma-delimited formatto a the remote computer 140, modified, and returned to database 122.This eliminates the need to activate and assign passcodes one by one,especially if hundreds of passcodes are being generated.

FIG. 14 depicts the passcode troubleshooting web page 1401 feature. Bysubmitting a passcode on this web page to interface 133, web server 130will analyze the submitted passcode and display a message in window 1405indicating the reason why the passcode is not valid (e.g., the accountis expired, the maximum number of conferences has been reached, thepasscode is not activated, the user is not activated). Those skilled inthe art will recognize that when managing large numbers of subscribers,it is more efficient to have the system determine the cause of potentialproblems with a passcodes.

Billing server 120 cycles through a checklist of items to check todetermine the cause of a problem. If any of these items are returned as‘true’ a message is compiled and displayed in a pop-up window 1405. Thiswindow 1405 might contain one or more elements that need to be correctedbefore a passcode can be used again. FIG. 15 depicts a subscriber statusweb page 1501 in which, passcodes that are expired, unassigned orinactive are displayed in red in column 1505.

FIG. 17 depicts the traffic feed web page 1701 which is valuable tocommercial teleconferencing service providers that resell bridgeconferencing services and must be able to quickly retrieve billinginformation from database 122. Web page 1701 allows information to bedownloaded from database 122 to remote computer 140 based on: the daterange of conference activity; the type of billing record (Conferences orParticipants). In addition, the file format (Comma Delimited or XML) andthe date format of the information to be downloaded may be specified.

In the preferred embodiment, the data may be displayed and downloaded intwo data formats, Conference and Participant. The data is arranged in aone-to-many formal, one conference with many participants. Mostcommercial service providers need to differentiate between the two inorder to properly bill their respective customers for the calls.

In addition, the present invention supports the transmission and receiptof data in traditional comma-delimited format as well as XML format. Inaddition, billing server 120 formats the data to be downloaded to remotecomputer 140 in a ZIP formatted file thereby reducing download time forusers with slower Internet connections.

Referring to FIG. 18 and FIG. 19, the present invention also providesonline invoicing tools. This powerful feature displays a real-timepreview of any invoice. After a billing cycle has been closed, invoicesare also available for display via web interface 133.

A pricing module is depicted in FIG. 18 and FIG. 19. Specifically, FIG.18 depicts a provider pricing model display web page 1801. Web page 1801allows pricing breakpoints to be applied to transactions 200 and relatedbilling information stored in database 122. In addition, web page 1801allows various volume discounts to be applied.

FIG. 19 depicts a provider pricing model entry web page 1901. Webinterface 133 analyzes the information entered into web page 1901 toensure that a user doesn't incorrectly create overlapping breakpoints,or having price points that don't add up correctly. In the preferredembodiment, this option does not appear on the available menu choicesfor a user who does not have at least a Level 5 access.

Referring again to FIG. 19, to create a new pricing model, informationis supplied to interface 133 via web page 1901: which includes thenumber of pricing levels; the number of conference minutes between eachlevel; the starting rate per minute of bridge usage and the rate todecrement per level.

FIG. 20 and FIG. 21 depict various versions of an invoice list web page2001 and totals mode invoice display web page 2101. Web pages 2001 and2101 are used to create invoices such as the printable invoice 2201displayed in FIG. 22. Web server 130 can retrieve information fromdatabase 122 for display via interface 133 upon request. In thepreferred embodiment, only web users with Level 4 access are permittedto view web pages 2001 and 2101.

To generate and display an invoice, a provider must be selected frompull-down menu 2105. Web page 2001 displays a list of all invoicescurrently generated for the selected provider. Web page 2001 summarizesthe invoice period, any description of the service, and a total amountdue for each invoice. Selecting a displayed invoice number displays theselected individual in the format of web page 2101. This informationincludes: Invoice date; provider information; date last generated; totalamount due; effective billing date; conferencing rate and dial-out andsurcharge minutes.

The invoice also displays the billable activity of each customer anddepartment levels (as created in the tiered hierarchy). Links to detailsof the sub-levels are provided.

Those skilled in the art will recognize that printing from a web browsercan often generate unpredictable output. Graphics, inconsistent pagebreaks and browser overhead often prevent users from printing formaldocuments from the web.

The present invention offers a solution in providing printable pagewindows. Pressing the Print button from anywhere in the applicationbrings up a pop-up window (not shown) with a printer-friendly version ofthe page or report. The same holds true for invoices, such as theprintable invoice 2201 displayed in FIG. 22.

The present invention also automates the traffic retrieval process. Acustomer isn't restricted to manually downloading traffic files from aweb page, rather, the ability to automate this process between acustomer's billing engine and the present invention is provided asfollows.

Using an HTTP request, a customer can request data, for a specific timeperiod, from database 122 to be downloaded to remote computer 140. AnSSL connection is established between the remote computer 140 and theweb interface 133 to provide security. Once the request is made, anActive Server Page (ASP) page (residing on web server 130) makes aconnection to the database 122, runs a query, and passes the data backto remote computer 140 via an HTTP data stream.

Web interface 133 also provides an automatic traffic feed option.Additional parameters must be provided in order for the request to beprocessed by web server 130. The following Table 7 is a list of bothrequired and optional parameters.

TABLE 7 Parameter Description User REQUIRED - Contains the username thatis making the request. This user must already exist in the system priorto making the request. This is the same username that is used to accessthe web interface 133. The username is not case sensitive: PassREQUIRED - Contains the password associated with the username. While theoriginal password is case sensitive, its encrypted string is not. Thepassword is the only parameter that must be encrypted. The purpose ofencrypting the password is to prevent unauthorized access web interface133 by individuals obtaining the URL (from a browser's history forexample). In the preferred embodiment, the password must be encryptedusing the following steps: 1. Convert each character to its ASCII value2. Subtract 25 from each value 3. Subtract the position of each value(starting with 1) from each value 4. Convert each resulting value to HEX5. Reverse the final string StartDate OPTIONAL - The starting date ofthe range of data being requested. If not present or an invalid date isprovided, the date one day prior to the current date will be used. Mustbe in the following format M/D/YYYY. EndDate OPTIONAL -The ending dateof the range of data being requested. If not present or an invalid dateis provided, the starting date will be used. If the StartDate andEndData parameters are the same, only one day's data will be returned.Must be in the following format M/D/YYYY. Type OPTIONAL - The type ofdata being requested. The only valid values are “C” to request a list ofconferences and “P” to request a list of participants. If not present oran invalid value is provided, “C” will be used. Format OPTIONAL - Theformat of the data being returned. The only valid values are “Comma” and“XML”. If not present or an invalid value is provided, “Comma” will beused and the data will be returned in comma-delimited format. If “XML”is used, the Type parameter will be ignored because the returned datawill contain both conferences and their participants is a hieraticalstructure. DateFormat OPTIONAL - The format of the date field beingreturned. The only valid values are “US” and “NonUS”. If not present oran invalid value is provided, US will be used. When set to US, thereturned date fields will be in M/D/YYYY format. When set to NonUS, datefields will be formatted using D/M/YYYY.

When needed, web server 130 will return errors in place of data. Thefollowing Table 8 identifies a list of possible error messages and theircauses.

TABLE 8 Error Message Cause Invalid Username Either no username wasprovided or the username was not found in the database. Invalid PasswordEither no password was provided or the password did not match the user'spassword when decrypted. No Data No data was available for the daterange specified in the request.

Referring again to FIG. 1, those skilled in the art will recognize thatbecause MAT 104, listener 114, billing server 120 and web server 130 arepreferably implemented as software residing on a workstation or otherprocessing platform, it is possible to combine or rearrange thefunctionality of the various devices. For example, listener 114 could beeliminated, and billing server 120 programmed to implement some or allof the functionality of listener 114. Furthermore, those skilled in theart will recognize that billing server 120 and web server 130 can becombined and executed on a single general workstation.

Similarly, FIG. 1 identifies several connections between variouscomponents. For example, Internet 135 is described as connecting webserver 130 to remote computer 140. Those skilled in the art willrecognize that other data connections, such as a circuit basedconnection, could be substituted for interne connection 135.

Other configurations are possible. For example, FIG. 23, discloses analternative embodiment of the present invention. Components having thesame function as described in FIG. 1 have retained the same numericalidentification. FIG. 23 discloses, the use of a combined MAT 2304connected to bridge 102, combined database 2307 and internet 135 viainterface 2333. Combined MAT 2304 contains the functionality of MAT 104,listener 114, billing server 120 and web server 133. Those skilled inthe art will recognize that the use of combined MAT 2304 reduces thecosts associated with multiple devices. Such a configuration, however,may be less reliable because of lack of redundant databases andworkstations.

Another embodiment, shown in FIG. 24 discloses a method andconfiguration for controlling multiple bridges 102, by using multiplelisteners 114. Components having the same function as described in FIG.1 have retained the same numerical identification. In this particularembodiment, MAT 104 is connected to multiple listeners 114.

FIG. 24 and FIG. 25 describes in greater detail the process used tocontrol the system 100 of the present invention. As shown in step 2500 auser accesses system 10 to create an account for an attendee and eitherassigns or has system 10 automatically create appropriate host or guestpasscodes for each user. At step 2505, this information is replicated tothe listeners 114 connected to MAT 104. At step 2510, the attendee usinga telephone 108 connects to bridge 102 via PSTN 106 or IP connection 110and upon connecting, bridge 102 prompts the attendee to enter a guest orhost passcode.

Step 2515, is similar to steps 306 through 312 described in FIG. 3.Specifically, bridge 102 has the MAT 104 that is connected to it searchits corresponding database 107 to determine whether the passcode enteredby the attendee matches the passcode to a conference call currently inprogress on that bridge 102. If the entered passcode matches thepasscode of a conference already in progress, the attendee is placedinto that conference. If the passcode does not match the passcodeassociated with a conference currently in progress, the bridge 102 hasthe MAT 104 connected to it search its database 107 to determine whetherthe passcode entered by the attendee matches the passcode associatedwith a conference that is scheduled to start around the time of theattendee's call. If the entered passcode matches the passcode of aconference that is scheduled to start around the time of the attendee'scall, the attendee is placed into that conference. If the enteredpasscode does not match the passcode of a conference that is scheduledto start around the time of the attendee's call, bridge 102 issues aquery to database 116 attached to the listener or listeners 114connected to the MAT 104 that is connected to the bridge 102 making therequest, to determine whether the entered passcode is a valid passcode.If the entered passcode is a valid passcode, bridge 102 creates aconference and the attendee is placed into that conference. If theentered passcode is not n valid passcode the call is terminated at step314.

As previously mentioned, some embodiments of the present inventionprovide for systems and methods to handle situations when two or moreparticipants are to be linked in a common communication session, butthat may have attempted to join the common communication session bydialing into two or more separate bridges.

FIG. 26 illustrates an exemplary dynamically linked bridge 2600 formedusing a bridge coordinator 2640 in accordance with one or moreembodiments of the present invention. In the illustrated embodiment, oneor more dial-in participants desiring to initiate a communicationsession, such as a conference call, dial into bridge A 2610. Inaddition, one or more dial-in participants desiring to participate inthe same communication session dial into bridge B 2620. As will bediscussed in more detail below, bridge A 2610 and bridge B 2620 mayregister with a central database 2630.

Bridge coordinator 2640 monitors central database 2630 and determineswhen dial-in participants desiring to participate in the samecommunication session have accessed different bridges. In someembodiments, bridge coordinator 2640 may be a software application. Inother embodiments, bridge coordinator 2640 may be implemented in acombination of hardware, software, and/or firmware. Physically, bridgecoordinator 2640 may be collocated or embedded with one of the bridges.In other embodiments, bridge coordinator 2640 may be an independentserver communicably coupled with a database and/or one or more of thebridges within the communications network. Still yet, in otherembodiments bridge coordinator 2640 maybe combined with central database2630.

According to one embodiment of the present invention, bridge coordinator2640 is able to determine when dial-in participants desiring toparticipate in the same communication session have accessed a bridge onthe network. In some embodiments of the present invention, thisdetermination is made by monitoring passcodes. Passcodes may be issuedin pairs comprising a host or moderator passcode and a guest passcode.The host passcode generally allows for the user to perform one or moreadministrative functions associated with the call. Examples ofadministrative functions include, but need not be limited to,starting/stopping the communication session, initiating recordings,disconnecting participants, and/or the like. Participants using theguest passcode, in contrast, may be limited to controlling one or morefeatures of their own communication link.

As mentioned, bridge coordinator 2640 may determine when dial-inparticipants desiring to participate in the same communication sessionhave accessed different bridges. In one embodiment, bridge coordinator2640 recognizes when passcodes of the same set, host and/or hostpasscodes, are in use on one or more bridges. According to oneembodiment, bridge coordinator 2640 may poll, or seek information from,the bridges in the network. This information may include thecommunication session passcodes associated with that participant. Otherinformation about the communication session may include the location ofthe bridge, a bridge identifier, a port number, and/or the like. Inother embodiments, each bridge in the network reports informationrelating to all of the communication sessions being routed through thatbridge to central database 2630. Central database 2630 may report thisinformation to bridge coordinator 2640 on a predetermined schedule whichmay be periodic or predefined in a look-up table. Other embodimentsprovide bridge coordinator 2640 the ability to poll the database forinformation relating to the communication sessions occurring on thenetwork. In one embodiment, bridge coordinator 2640 stores the hostpasscode of all active sessions found. Then, when a new guest passcodeis found, bridge coordinator 2640 determines if there is a matching hostpasscode present.

When bridge coordinator 2640 determines that dial-in participantsdesiring to participate in the same communication session have accesseddifferent bridges, bridge coordinator 2640 may then identify a host fora particular communication session. This may be done, for example, usingthe information collected from the central database, the bridges in thenetwork, and/or using information stored within bridge coordinator 2640.According to one embodiment, a host is identified by the host passcode.If multiple host passcodes have been used for the same communicationsession, then according to one embodiment, bridge coordinator 2640 mayselect as the host bridge the bridge with which the host passcode wasregistered first in time.

Once a host bridge is identified or selected by bridge coordinator 2640,information may then be collected about the host bridge. For example,information about the host bridge may include, but need not be limitedto, a dial-up number, an IP address, physical location, and/or the like.In one embodiment, information about the host bridge may be collected byperforming a look-up from a dial-string table within central database2630. In some embodiments, the dial-string look-up table may containinformation relating to the phone number of bridge B 2620 and thelocation of bridge A 2610. In one embodiment, the look-up table may bepopulated with the bridge information by an administrator at the time abridge is added to the network. In another embodiment, the bridges areconfigured to automatically send information to populate the look-uptable on predetermined schedule (e.g., a periodic schedule or on a userdefined schedule).

In any event, once the phone numbers and locations are determined,bridge coordinator 2640 initiates a dial-out command from bridge A 2610to bridge B 2620. Following an appropriate validation process, theparties will be joined. According to one embodiment, the validationprocess comprises checking the that the host and guest passcodecorrespond to the same communication session. In some embodiments,encrypted validation keys may be sent from each bridge to the bridgecoordinator. In this case, the bridge coordinator will decrypt the keyand verify that the parties should be joined.

The following example illustrates one approach for joining acommunication session between multiple participants using DBL inaccordance with an embodiment of the present invention. Suppose a callerA dials into bridge A 2610 by using a telephone number. Once bridge A2610 answers the caller may be prompted to enter a passcode which wasassigned to the communication session he desires to join. The passcodemay then be validated by the system and the communication session isstarted at bridge A 2610. According to one embodiment, the validationprocess may comprise looking up the passcode in a predefined list. Inother embodiments, the passcode validation process may comprisedetermining a certain characteristic of the passcode is present. Forexample, in order for a passcode to be valid one or more of thefollowing properties may need to be present: the passcode is divisibleby a certain number, the sum of the digits of the passcode are even, orany other scheme know to those skilled in the art. Once the validationprocess is complete, an, entry may then be made in a database tablelocated in a central location database 2630 indicating that caller A isonline. One example of such a table is presented in FIG. 31. Accordingto one embodiment, bridge A 2610 initiates a transmission to centraldatabase 2630 that caller A is online. In another embodiment, centraldatabase 2630 polls each bridge in the network to determine whichcallers are online and make the appropriate recordation in the databasetable. In either case, the entry in database 2630 may include one ormore call parameters. For example, the entry may include the bridge ID(i.e., an identifier unique to the bridge connecting caller A to thenetwork), a port number of the bridge through which the call is beingrouted, and a passcode entered by the participant.

Similarly, when caller B dials into bridge B 2620 desiring to join acommunication session, bridge B 2620 prompts caller B to enter apasscode for the desired communication session. The passcode may then bevalidated by the system. In one embodiment, the passcode is validated bybridge 13. In another embodiment, the passcode is validated by bridgecoordinator 2640. The validation process may comprise looking up thepasscode in a predefined list. In other embodiments, the passcodevalidation process may comprise determining a certain characteristic ofthe passcode is present. For example, in order for a passcode to bevalid one or more of the following properties may need to be present:the passcode is divisible by a certain number, the sum of the digits ofthe passcode are even, or any other scheme know to those skilled in theart. After the code is validated, communication session begins on bridgeB 2620. According to one embodiment, an entry is then made in a databasetable located in a central location indicated that caller B is online.This entry may result from bridge B reporting that caller B is onlineonce the validation process is complete. As another example, centraldatabase 2630 may poll bridge B on a predefined schedule. In someembodiments, the database entry makes note of one or more of the callparameters such as the bridge ID (i.e., an identifier unique to thebridge connecting caller B to the network), port number associated withbridge B through which the communication session is being routed, apasscode that was entered by caller B, and/or the like.

However, bridge B 2620 is unaware that the same communication session isalready in progress on bridge A 2610. In addition, bridge A 2610 isunaware that the same communication session is already in progress onbridge B 2620. According to one embodiment, bridge coordinator 2640monitors the activity of all the bridges. In some embodiments bridgecoordinator 2640 monitors the bridge activity by polling centraldatabase 2630 in which entries are present regarding activecommunication sessions. In other embodiments, bridge coordinator 2640sends a request to each bridge requesting information about activecommunication sessions. In some embodiments, the information returned byeither the bridge coordinator or the bridges contain the communicationsession passcodes that were entered by the callers. When bridgecoordinator 2640 recognizes the passcodes assigned to the samecommunication session, bridge coordinator 2640 determines a bridge thatwill act as a host bridge for the communication session.

According to one embodiment, a host bridge is the bridge through whichthe communication session will be routed. In some cases, determining abridge that will act as a host bridge may be done by determining if thebridge is associated with a host passcode. In other instances,additional information may be used to determine if the bridge should bea host bridge. For example, suppose caller B dials into bridge B 2620and enters a host passcode. In this case, bridge coordinator 2640 mayalso determine if bridge B has available capacity to host thecommunication session, if bridge B provide the least cost for routingthe communication session (i.e., least cost routable), and/or the like.If it is determined that bridge B does not have the available capacity,bridge coordinator 2640 may determine an alternate bridge to act as ahost bridge. Again, this may be done using one or more of a variety ofselection criteria such as bridge capacity, least cost routable, and/orthe like.

Once a host bridge is determined, the bridge controller may perform alook-up from a dial-string table within central database 2630 todetermine the phone number of host bridge. According to someembodiments, the dial-string table may also contain the location of thehost bridge. Once the phone numbers and locations are determined, bridgecoordinator 2640 may initiate a dial-out command from the other bridgesassociated with the communication session to the host bridge.

As previously described, in many situations there will be a host andguest passcode. So, multiple hosts may dial into a call, and it is thehost who has control over the call's functionality. The callers with theguest passcode generally have a non-managerial role in the call. Assuch, according to one embodiment, the bridge that contains a hostparticipant that dialed in first will become the host bridge, i.e., itis from this bridge where all linking of the communication session willoccur. For sake of explanation, assume that bridge A 2610 is the hostbridge.

In that case, continuing with the detailed call flow, the bridgecoordinator will instruct bridge A 2610 to initiate a dial-out to thebridge B 2620. According to one embodiment, this dial-out process ringsthe remote bridge, bridge B 2620, and on answer, will send via a DTMFstring, the guest passcode of the call. In some embodiments, thepasscode will be validated and the line joined into the communicationsession, thus linking the two bridges.

This process may be repeated for each subsequent bridge containing aparticipant using either the host of guest passcode from the same set.Then, at the conclusion of the call, the host will end the communicationsession by automatically tearing down all the linked lines to the otherbridges.

FIG. 27 illustrates a flow diagram of call routing in accordance withsome embodiments of the present invention. As illustrated, a bridgereceives a call at block 2710. The call may originate from a callparticipant, an endpoint, another bridge, or from any other piece oftelecommunications equipment. Once the call is received at the bridge,the bridge identifies information about the call. Examples of callinformation including originating number, destination number, timestamp, and/or the like. The bridge may identify call information ordetails in one or more ways depending on the type of communicationsession associated with the call. For example, the call may haveassociated header files which may be appropriately interpreted. Once thecall information is determined, at block 2720 the call details areupdated in the bridge. One or more of these call details along withrelevant information about the bridge may then be reported to the bridgecoordinator at block 2730. According to one embodiment, the reporting ofthe information may be initiated by a predetermined event such as arequest from the bridge coordinator, a predefined period of time haselapsed, and/or the like. Examples of the type of information that maybe incorporated in the call and bridge details may include, but need notbe limited to, bridge identifier 2740, call status 2750, bridge status2760, and the like.

At block 2770, the bridge coordinator then determines if the bridgewhich received the call is a host bridge. In one embodiment, a bridge isdetermined to be a host bridge if the communication session which isbeing routed through the bridge has provided a host passcode. If thebridge coordinator determines that the bridge is not a host bridge, thenthe bridge coordinator waits at block 2780 for call details from anotherbridge. If the bridge coordinator determines that the bridge is a hostbridge, then all calls relating to the corresponding communicationsession will be routed via the host bridge at block 2790.

FIG. 28 illustrates a flow diagram of another call routing method inaccordance with other embodiments of the present invention. Asillustrated, a bridge receives a call (block 2710). The call may be partof a communication session such as a teleconference, a video conference,and/or the like. The call may originate from a call participant, anendpoint, another bridge, or from any other piece of telecommunicationsequipment located within or outside of the bridge network. Once the callis received at the bridge, the bridge identifies information about thecall. Call information may include, for example, originating number,destination number, time stamp, and/or the like. This information may becontained within the call in a variety of manners. For example, a callidentifying message may be sent along with the call, call identifyinginformation may be contained within a packet based communicationsprotocol, and the like. The call details are updated in the bridge(block 2720). One or more of the aforementioned call details along withinformation about the bridge may be reported to the bridge coordinator(block 2730). For example, this information may be transmittedwirelessly, through a telephone line, over a LAN, and/or the like.Examples of the type of information that may be incorporated in thecall/bridge details may include, but is not limited to, bridgeidentifier 2740, call status 2750, bridge status 2760, call participant,passcode, and/or the like.

With the call thus identified, the bridge coordinator determines if twoor more calls are accessing the same communication session (block 2810).According to some embodiments, this may be done by verifying andmatching the passcodes provided by the participants as previouslydescribed. If two or more calls are not attempting to access the samecommunication session (block 2810), the bridge coordinator waits forcall details from another bridge (block 2780). In contrast, where thebridge coordinator determines that two or more calls are attempting toaccess the same communication session (block 2810), the bridgecoordinator determines if the bridge which received the call should bethe host bridge (block 2770). According to some embodiments of thepresent invention, a determination that two or more calls acre accessingis done by checking the passcode associated with the calls. If thepasscode is a host passcode then the bridge may be a host bridge. Whereit is determined that the bridge is not a host bridge (block 2770), thebridge coordinator waits at block 2780 for call details from anotherbridge.

If the bridge coordinator determines that the bridge is a host bridge(block 2770), the bridge coordinator determines if the bridge has thecapacity to accept the current communication session (block 2820).According to some embodiments of the present invention, this may be doneby polling the bridge to query capacity. In response, the bridge mayindicate a utilization level that may in turn be compared with apredetermined capacity threshold. Thus, for example, it may bedetermined whether the bridge is more than eighty percent utilized. Inother embodiments of the present invention, the capacity of the bridgeis transmitted to the bridge coordinator along with the call/bridgeinformation. This information may be maintained in a table that isaccessed whenever a determination of capacity is to be made. In eithercase, the bridge coordinator may estimate the bandwidth needed for thecommunication session based at least in part on the call informationprovided by the bridge and then determine if the bridge has sufficientcapacity.

If the bridge is found to have sufficient capacity (block 2820), thenthe bridge coordinator determines if routing the call through theidentified bridge would satisfy a desired load balance (block 2825).This may include, for example, determining whether another possiblebridge is underutilized in comparison to the identified bridge orwhether the identified bridge is over-utilized in comparison with otheravailable bridges. The intent of making such a determination is toassure that a general balance is maintained between available bridges.Thus, various load balancing algorithms known in the art may be utilizedto first make the determination of an allowable load balance and/or ofanother choice of bridge that would satisfy the desired load balance.

Where it is determined that the identified bridge satisfies desired loadbalance conditions (block 2825), it is determined whether choice of thebridge is least cost routable (block 2830). Least cost routing mayconsider one or more factors including, but not limited to, financialcosts, quality of service, available service levels, and/or the like. Asone example, least cost routable may be simply the lowest financial costfor performing a communication session. Thus, for example, where one ormore PSTNs (phone systems) is being used in relation to thecommunication session, it may be determined which of the PSTNs providesthe most advantageous rate structure for the call. Where it isdetermined that the identified bridge offers least cost routing (block2830), all calls associated with the communication session are routedvia the identified host bridge (block 2790). A table may be maintainedthat provides rates based upon geography that may be accessed to performthe aforementioned least cost routing example.

Alternatively, where it is determined that the identified bridge doesnot have capacity (block 2820), selection of the identified bridgeresults in a substantial load imbalance (block 2825), or that selectionof the identified bridge does not result in least cost routing (block2830), then another bridge is identified through determining analternate bridge that does have capacity (block 2840), does satisfy adesired load balance (block 2845), and in some cases provides for leastcost routing (not shown). In such a case, all calls associated with thecommunication session are routed via the alternative host bridge (block2850).

FIG. 29 illustrates another exemplary dynamically linked bridge formedusing a bridge coordinator in accordance with various embodiments of thepresent invention. FIG. 29 is similar to the logical diagram describedwith respect to FIG. 26, but where more than two bridges need to beconnected. In addition to bridge A 2610 and bridge B 2620, one or moredial-in participants to a communication session have also accessedbridge C 2910 and bridge D 2920. As previously described bridgecoordinator 2640 monitors the activity of all the bridges. Again, thismay be done in a variety of ways. In one embodiment, bridge coordinator2640 may wait for updates from each of the bridges. In otherembodiments, bridge coordinator 2640 polls central database 2630 whichcontains information reported by the bridges. Still yet, in otherembodiments, bridge coordinator 2640 polls the bridges independently.Then bridge coordinator 2640 determines how to route the call. Forexample, one embodiment of a method which bridge coordinator 2640 mayuse to decide how to route the call was described in FIG. 28.

FIG. 30 provides a more particular example of dynamically linked bridgesillustrating particular geographies and endpoints that may be servicedusing systems and methods in accordance with one or more embodiments ofthe present invention. In FIG. 30, participant 3010 dials into Denverbridge 3020. The bridge answers and prompts the participant to enter acommunication session passcode. Participant 3010 enters a host passcode,which in this particular case is ‘1234’. Denver listener server 3030receives information about the conference call and the participantsusing Denver bridge 3020. According to some embodiments of the presentinvention, listener server 3030 comprises listener software which isconfigured to make a TCP connection to a maintenance operating terminal(MAT) associated with Denver bridge 3020. According to variousembodiments, the MAT may provide one or more of the following: telephonyline setup and control, system feature configuration, logging andtroubleshooting, and/or the like. The listener server software may befurther configured to exchange messages with the MAT. One example ofmessages exchanged includes passcode validation messages. As such, whena participant's passcode is verified, a valid messages may be sent fromthe listener server to the Denver bridge 3020. According to oneembodiment, a copy of the verification messages are also sent to bridgecoordinator 3040. At this point a message may also be sent to a centraldatabase indicating that a participant has activated a conference onDenver bridge 3010. In some instances, MAT software may be commerciallyavailable. For example, one such example of commercially available MATsoftware may be purchased through Compunetix, Inc.

Then, in the exemplary situation depicted, participant 3050 dials intoLondon bridge 3060 using a guest passcode, which in this particular caseis ‘23456’. An entry may then be made in the central database indicatingthat a guest intended for the ‘12315’ conference tins dialed in toLondon bridge 3060. At this point, Denver bridge 3010 receivesinstructions from bridge coordinator 3040 to initiate a dial-out call toLondon bridge 3060. Then, the system joins all the participants. Thisprocess is repeated for the third participant 3080 who dials into Sydneybridge 3090 with associated Sydney listening server 3095.

In some embodiments, a listener server may be installed with softwarethat will detect any loss of communication with either the database orbridge. Listener server may then begin a resynchronization process oncethe failed component regains complete functionality. During thisresynchronization process, listener server 3030 will re-poll the bridges(MATs) and re-request all the information regarding active ports.

FIG. 31 illustrates an exemplary presence table which may be used inaccordance with one embodiment of the present invention. Presence table3100 provides a system for tracking the active participants on all ofthe bridges. In the embodiment depicted, presence table 3100 includes abridge id 3110, a date and time 3120 the conference was initiated,passcode 3130, and port number 3140 on the bridge to which theparticipants are connected. According to one embodiment, a bridgecoordinator may use this table to determine the location of allparticipants of a call regardless of the participant's location.

FIG. 32 illustrates an exemplary table containing PSTN dial-out numberswhich may be used in accordance with one embodiment of the presentinvention. When initiating a dial-out call, the bridge coordinator willneed to know what number to dial. According to one embodiment, in a PSTNconfiguration, the bridge coordinator may access a table, such as table3200, which contains the appropriate number to dial by querying thedatabase for the dial string from the originating bridge to thedestination bridge.

FIG. 33 illustrates an exemplary table containing IP dial-string whichmay be used in accordance with one embodiment of the present invention.Similar to the PSTN table illustrated in FIG. 32, an IP table, such astable 3300, may be used when the call is being routed over an IPconnection. In this instance, the bridge coordinator will query adatabase for the IP address of the bridge to dial. In some embodiments,additional information may also be provided including the port number,codec to use, IP header prefix, and the like.

Although the present invention has been described in connection withbridges that are connected to telephones, those skilled in the art willrecognize that the present invention can be used in connection with abridge suitable for video conferencing without departing from the scopeand spirit of the present invention.

Embodiments of the present invention include various steps, which havebeen described in detail above. A variety of these steps may beperformed by hardware components or may be embodied in computerexecutable instructions, which may be used to cause a general-purpose orspecial-purpose processor programmed with the instructions to performthe steps. Alternatively, the steps may be performed by a combination ofhardware, software, and/or firmware. As such, FIG. 34 is an example of acomputer system 3400 with which embodiments of the present invention maybe utilized. Such a computer system may include, but is neither limitedto or required to include, a bus 3401, at least one processor 3402, atleast one communication port 3403, a main memory 3404, a removablestorage media 3405 a read only memory 3406, and a mass storage 3407.

Processor(s) 3402 can be any know processor, such as, but not limitedto, an Intel® Itanium® or Itanium 2® processor(s), or AMD® Opteron® orAthlon MP® processor(s), Motorola lines of processors, a Digital SignalProcessor (DSP), and/or the like. Communication port(s) 3403 can be anyof an RS-232 port for use with a modem based dialup connection, a 10/100Ethernet port, or a Gigabit port using copper or fiber. Communicationport(s) 3403 may be chosen depending on a network such a Local AreaNetwork (LAN), Wide Area Network (WAN), or any network to which thecomputer system 3400 connects.

Main memory 3404 can be Random Access Memory (RAM), or any other dynamicstorage device(s) commonly known in the art. Read only memory 3406 canbe any static storage device(s) such as Programmable Read Only Memory(PROM) chips for storing static information such as instructions forprocessor 3402. Mass storage 3407 can be used to store information andinstructions. For example, hard disks such as the Adaptec® family ofSCSI drives, an optical disc, an array of disks such as RAID, such asthe Adaptec family of RAID drives, or any other mass storage devices maybe used. Bus 3401 communicatively couples processor(s) 3402 with theother memory, storage and communication blocks. Bus 3401 can be aPCI/PCI-X or SCSI based system bus depending on the storage devicesused. Removable storage media 3405 can be any kind of externalhard-drives, floppy drives, IOMEGA® Zip Drives, Compact Disc-Read OnlyMemory (CD-ROM) Compact Disc-Re-Writable (CD-RW), Digital VideoDisk-Read Only Memory (DVD-ROM). The components described above arerecant to exemplify some types of possibilities. In no way should theaforementioned examples limit the scope of the invention, as they areonly exemplary embodiments.

The invention has now been described in detail for purposes of clarityand understanding. However, it will be appreciated that certain changesand modifications may be practiced within the scope of the appendedclaims. Thus, although the invention is described with reference tospecific embodiments and figures thereof, the embodiments and figuresare merely illustrative, and not limiting of the invention. Rather, thescope of the invention is to be determined solely by the appendedclaims.

1. A method for interconnecting real-time communication links, themethod comprising: receiving a first status associated with a firstcommunication link, wherein the first communication link is establishedbetween a first endpoint and a first bridge in a network; receiving asecond status associated with a second communication link, wherein thesecond communication link is established between a second endpoint and asecond bridge in the network; selecting one of the first bridge and thesecond bridge to operate as a host bridge, the selecting based at leastin part on the first status and the second status; and after receivingboth the first status and the second status, automatically causing theselected host bridge to initiate a third communication link with thenon-selected one of the first bridge and the second bridge.
 2. Themethod of claim 1, wherein the selecting the host bridge includesconsideration of whether the first status indicates a host status, andwhether the second status indicates the host status.
 3. The method ofclaim 1, wherein the selecting the host bridge includes consideration ofwhether the first bridge has sufficient available capacity.
 4. Themethod of claim 3, wherein the selecting the host bridge includesconsideration of whether the second bridge has sufficient availablecapacity.
 5. The method of claim 1, wherein the selecting the hostbridge is based at least in part on the determination of whether one ofthe first bridge and the second bridge is least cost routable.
 6. Themethod of claim 1, the method further comprising: recording a firstentry in a database table, wherein the first entry includes a firstplurality of call parameters related to the first communication link;and recording a second entry in the database table, wherein the secondentry includes a second plurality call parameters related to the secondcommunication link.
 7. The method of claim 6, wherein the firstplurality of call parameters includes at least one parameter selectedfrom a group consisting of: a bridge identifier, a call status, a portnumber, a conference passcode, and a bridge status.
 8. The method ofclaim 6, wherein the first status associated with the firstcommunication link is received by polling the database table.
 9. Themethod of claim 1, wherein the automatically causing the host bridge toinitiate a third communication link includes monitoring a databasepopulated with a plurality of communication link status information toidentify when the first communication link and the second communicationlink have been established.
 10. The method of claim 1, wherein theinitiating a third communication link comprises: determining an accessproperty of the non-host bridge; communicating with the non-host bridgeusing the access property; and transmitting a validation code from thenon-host bridge to the host bridge.
 11. The method of claim 10, whereinthe validation code is a guest passcode.
 12. A computer-readable storagemedium containing a set of instructions capable of causing one or moreprocessors to: receive a first status associated with a firstcommunication link, wherein the first communication link is establishedbetween a first endpoint and a first bridge in a network; receive asecond status associated with a second communication link, wherein thesecond communication link is established between a second endpoint and asecond bridge in the network; select one of the first bridge and thesecond bridge to operate as a host bridge, wherein the selection isbased at least in part on the first status and the second status; andcause the host bridge to initiate a third communication link with thenon-selected one of the first bridge and the second bridge afterreceiving both the first status and the second status.
 13. A method forinterconnecting real-time communication links, the method comprising:receiving a first status associated with a first communication link,wherein the first communication link is established between a firstendpoint and a first bridge in a network, and wherein the first statusincludes information related to the first communication link; receivinga second status associated with a second communication link, wherein thesecond communication link is established between a second endpoint and asecond bridge in the network, and wherein the second status includesinformation related to the second communication link; determining a hostbridge based at least in part on the first status; dynamically linkingthe first bridge to the second bridge based at least in part on thefirst status and the second status, wherein the host bridge operates tointerconnect a multi-party communication ongoing between at least thefirst endpoint and the second endpoint.
 14. The method of claim 13further comprising: determining that the second bridge is the hostbridge based at least in part on the second status; receiving a thirdstatus associated with a third communication link, wherein the thirdcommunication link is established between a third endpoint and a thirdbridge in the network; and dynamically linking the third communicationlink to the first communication link and the second communication linkby creating a fourth communication link between the host bridge and thethird bridge.
 15. The method of claim 13, wherein the first statusincludes at least one parameter selected from a group consisting of: abridge identifier, a call status, a port number, a conference passcode,and a bridge status.
 16. The method of claim 13, wherein the determiningthe host bridge based at least in part on the first status includesdetermining if a call passcode associated with the first communicationlink was a host passcode or a guest passcode.
 17. A method of monitoringa teleconference bridge having a plurality of ports for establishing ateleconference between two or more attendees comprising: generating oneor more transaction records in response to a change in the status of anyport on said teleconference bridge; storing the one or more transactionrecords in a first database connected to a first server; copying the oneor more transaction records stored in said first database to a seconddatabase connected to a second server; in response to a user commandreceived from a remote computer, transmitting at least one of the one ormore transaction records stored in the second database, to the remotecomputer via a remote connection.
 18. The method of claim 17 wherein theremote connection is a packet network.
 19. The method of claim 18wherein the remote connection is a circuit connection.
 20. A method ofcontrolling a teleconference system bridge having a plurality of portsfor establishing a teleconference between two or more attendeescomprising: generating one or more passcodes in a remote computer;transmitting the one or more generated passcodes from said remotecomputer to a first server via a remote connection; storing the one ormore passcodes in a first database connect to said first server; copyingthe one or more passcodes to a second database connected to a secondserver; comparing a user passcode received at a first port of saidteleconference bridge with the one or more passcodes stored in thesecond database; and establishing a teleconference between two or moreattendees when the user passcode matches at least one of the one or morepasscodes stored in the second database.